集群整体迁移测试策略实践
一、前置
云原生给各中小公司工程效率带来了很大的便利，多家云厂商的架构体系不完全相同，在选择云厂商以及业务上云的过程中，整体的集群切换会是一个比较复杂的课题。
酷家乐在2022年初进行了一次整体集群切割，实际的切换过程由于前期的认真准备和各项策略的实施取得了符合预期的效果。本文期望给做整体集群切换的质量团队做一个分享。
机房切割可能在自有机房和公有云之间的迁移，或者公有云间的迁移。酷家乐碰到的场景是在公有云之间做迁移，文中姑且描述为A云到B云的切换，A云为旧生产集群，B云为新集群。
集群迁移涉及到工作面非常多，选出部分关键内容进行分享。
二、目标和背景
| 目标 | 原因 | 测试挑战 |
|---|---|---|
| 切割后不能影响重要商家 | 重要核心商家功能不能有阻断，否则会带来公司信誉受损，甚至资损 | 主功能回归之外还要注意分支逻辑 |
务必一次切换成功 | 因为集群迁移整体回滚难度大，意味着二次切割，所以需要全力争取一次切换成功 | 回归测试务必充分 |
| 切割时间需控制在2小时 | 涉及国际业务线，国内白天为国外工作时段，业务方能接受的硬性要求，停服时间控制在2小时以内，几乎是多家其他公司做B云迁移史上的最严苛要求 | 前置准备需要充分 切割验证需要快速 |
有明确Deadline工作倒排 | 其一是春节是唯一长时间国内流量低峰期，风险可控，该时间为国内国际业务和商务同学沟通后的最佳时间。 其二项目涉及团队太多，每轮回归会牵扯多团队人员的投入，测试过程需要有连续性，否则可能面临二次测试的问题 | 验证效率需要保障，需要引入一些技术手段缩短时间 |
三、测试方案和策略
3.1 被测对象的分析
常规的项目被测对象为代码，但这次的迁移项目项目的测试对象实际为整个集群。
| 被测变量 | 项目内的分析 | 可能出现的问题和影响 |
|---|---|---|
| 代码 | 涉及到代码适配中间件改动，例如写死的逻辑和非标准逻辑，代码测试需要完成在A云环境和B云环境的测试 | 中间件访问失败，功能不可用 |
| 中间件 | 中间件主要涉及云环境的迁移，中间件参数配置的变化 | 核心功能访问失败，性能出现问题 |
| 配置 | 典型的例如zk配置和toad配置的变化，以及正确性 | 核心功能访问失败 |
| 网络拓扑 | 迁移后，由单A云部署为主，变更为A云、B云多云部署，部署后涉及各类服务调用状态是否正常 | 核心功能访问失败 |
| 域名 | 对公网域名不发生变化，部分对内域名由A云变更为B云 | 核心功能访问失败 |
没有环境就无法开展工作，环境集群搭建是整个项目中的基础环节，中间件和运维团队花费了大量的精力，作为质量团队主要是提供策略和要求。
基本原则：
屏蔽外网真实流量无法引入，测试过程不能影响真实用户。
测试集群尽量模拟线上真实的切换集群，能达到提前验证的目的。
思路：
由运维团队搭建真实集群，切换前为准线上集群，我们叫仿真集群，由中间件团队做初步的可用性验证。
仿真环境，中间件和存储在B云，与现有生产环境隔离的独立环境，数据和配置从A云全量同步。
拨入VPN或者通过独立的虚拟机可以访问仿真集群，仿真集群数据可反复重置，仿真环境的操作不影响实际业务。
3.3 多轮测试计划
| 阶段 | 步骤 | 验证方式 | 验证目的 |
|---|---|---|---|
| 1 | 原始A云环境测试 | 对代码改动进行验证，并发布到A云线上 | 代码中间件改动后的正确性，在A云环境发布和验证 |
| 2 | B云仿真beta环境冒烟测试 | 拨入vpn的方式，功能测试方式对B云的beta环境进行验证 | 快速完成冒烟测试，以及代码的第一轮修复 |
| 3 | B云仿真prod环境测试 | 拨入vpn的方式，功能测试方式对B云的prod环境进行验证 | 完成集群验收验证 |
| 4 | mirror流量回放测试 | 将线上流量转发到仿真集群，相同的数据条件下，对比集群的表现 | 性能水位评估，功能测试的补充流量 对网络拓扑层，域名层的问题进行发掘 |
| 5 | 针对集群的性能压测 | 通过goreplay的方式构造压测流量进行对比测试 编写测试脚本进行集群压测 | 集群迁移后会不会有性能瓶颈 |
| 6 | 内部公测 | 借助实施，客服，内部同事的力量进行一次bugbash | 发掘测试团队验证过程中的测试盲点 |
| 7 | 灰度测试 | 对线上部分用户做灰度用户引流测试 | 对真实场景引入进行验证，对ka，ska用户的复杂使用场景覆盖 |
| 8 | 灰度->prod环境回切验证 | 在prod环境内进行回归测试 | 确保切割交付前的仿真环境可用 |
| 9 | 切割验证 | 在开服前，最后一次数据同步完成后对环境做一轮验收 | 确保切割交付前的仿真环境可用 |
| 10 | 开服验证 | 全部变更完成后，基于真实网络，在公网进行验证 | 切割后的线上端到端验证 |
随着集群职责的演进产生了不同的测试阶段，事后回顾来看分阶段测试策略非常有必要。
四、典型实践分享
4.1 流量回放实践
4.1.1 背景分析
在时间紧张的情况下，能否有一些技术手段来协助回归测试，首先想到的是流量回放的测试，而实际我们在项目中大量的采用了该方案。
常用的流量回放测试手段对比选型：
| 手段分类 | 开源工具 | 酷家乐封装平台 | 分析 | 项目内用途 | 使用成本 | 参考配置连接 |
|---|---|---|---|---|---|---|
录制&回放 | goreplay | capplan性能测试平台 | http入口层录制线上流量后，在仿真集群进行回放进行验证，由于仿真集群的数据为隔离可重置，实际进行了大量的端到端式的全链路回放测试 | 用作集群性能测试，加速了脚本编写 | 中等 | https://blog.csdn.net/xqtesting/article/details/109722583 |
| 录制&回放 | SandBox | kurepeater流量回放平台 | 针对应用级的流量采集，提供较强的mock能力，在酷家乐内部实际基于sandbox构建了repeater平台进行了读接口的对比测试 | 部分应用的读接口使用该方式进行回归对比测试 | 中等 | http://testerhome.com/topics/25416 |
| 实时回放 | nginx mirror | - | 7层网络的实时转发，非常匹配本次项目的需求，只需要针对nginx增加少量配置 | 对线上的实时流量转发打入测试集群进行 | 较低 | https://cloud.tencent.com/developer/article/1495449 |
实时回放 录制&回放 | tcpcopy | - | 功能强大，能力可匹配项目诉求，但效果类似于nginx mirror，同时需要在生产环境机器安装额外软件，具有较高变更成本 | 未采用 | 较高 | https://www.cnblogs.com/zhengyun_ustc/p/tcpcopy.html |
4.1.2 动作
最终功能测试环节，核心借助A云生产 to B云生产进行nginx mirror回放测试过程来做回归和性能测试。
环境准备：
镜像流量可能会影响生产环境数据，生产服务，如何去避免？
仿真和生产网络隔离
仿真环境禁写部分存储资源
B云内调用公网导致的多次调用
通过域名黑名单形式禁用
仿真环境涉及三方的服务接口支持mock
原生产环境A云nginx负载问题
新增nginx机器，从6台扩展到12台
A云B云专线负载问题
日常网关流量为3G+，专线带宽扩到10G
A云B云两边数据一致性，在数据重置完成后立刻开始做流量回放
阶段 | 流量 | 应急方案 |
|---|---|---|
| 验证阶段 | 一台nginx 1%-50%流量 | 调整导流的nginx权重 |
| 验证阶段 | 一台nginx 100%流量 | 调整导流的nginx权重 |
| 验证阶段 | 全量100%流量 | 修改10台nginx配置并重载 |
| 验证阶段 | 两台nginx 100%流量 | 调整导流的nginx权重 |
| 正式阶段 | 全量100%流量 | 修改10台nginx配置并重载 |
正式阶段-二次验证 | 全量100%流量 | 调整5台nginx权重，修改配置并重启 |
分析流量回放数据：
分析网关层报错，根据http code和response返回。
分析集群内部dns层网络解析报错，配置错误的域名会导致网络层报错，从而留下错误日志。
分析应用的日志报错。
通过监控系统查看监控报错，做报错统计。
查看数据库内的数据变化。
4.1.3 结果
回放取得了比较好的效果，借助mirror回放发现了功能测试未注意到的问题，测试用例未覆盖，实际线上仍有流量。
大流量的情况下获取了中间件存储的性能基线数据，可用来做性能性能对比分析。
失败率的分析：流量存在报错的漏斗效应：入口流量抵达最终底层服务的只有部分成功，其余会被中间层拦截。
4.2 性能测试实践
集群的性能评估为成功切换提供了重要参考依据，在项目初期就进行性能测试计划和方案的评估。
性能测试的三个阶段：
项目的性能测试流程：
实际借助性能测试，发现了20+的性能问题，包括底层存储配置，已经配置改造缺失等，针对集群迁移的测试中尤其要考虑性能风险。
4.3 延时模拟实践
4.3.1 背景
可灰度是项目发布三板斧之一，能够提前的规避风险，但灰度环境的搭建过程中遇到一个评估难题，在此阶段A云B云需要同时提供服务，只能有一套存储，新集群应用部署在B云，存储和中间件部署在A云，会涉及到跨云访问，跨云访问即便走专线也会产生延迟增加。
问题：
如果将用户流量引入B集群，性能衰减是否客户能够接受，需要进行延时验证，但是如何模拟跨云延时？
解决办法：
借助tc工具进行网卡的延时模拟。
相关文档：tc manpage: https://man7.org/linux/man-pages/man8/tc-u32.8.html
下面命令模拟带有波动性的延迟值（在 90 ~ 110 之间波动）。tc qdisc add dev eth0 root netem delay 100ms 10ms
可针对K8S的Node，也可针对具体的pod，编写脚本后批量执行。
4.3.2 效果
搭建模拟环境之后，测试进行了一轮接口RT采集，部分的功能响应时间达到几十秒，不符合预期。
优化：将部分底层基础服务换回A云，这部分应用不参加灰度集群, 大幅减少底层接口的DB跨云访问，最终大部分用户端的RT符合预期，在灰度前避免了对用户的影响。
4.4 项目沟通过程实践
4.4.1 高效沟通
项目涉及50+的测试，200+的开发，实际的沟通成本非常高。
作为测试PM 避免自己成为瓶颈，注意避免1:50的沟通，而是找到接口人建立树状沟通，否则会非常痛苦。
4.4.2 有效沟通
发送了信息，但是对方不一定收到，对方收到信息，但是不一定理解。
TCP握手式的沟通，对重要的信息一定要以此形式。
4.4.3 善用在线化工具
搜集信息
在线表单>在线表格>线下表格>IM群里讨论，举例以下为企业微信的表单功能，优于在线表格管理。
企业微信的在线表单：
企业微信的在线表格：
切割过程中的问题搜集线上化，搭建看板，告别群内统计，例如汇总透明进展。
借助技术手段快速的搭建项目中使用小工具，会发现事半功倍。
五、后记
切割当天历历在目，在那难忘的两小时内，核心人员屏住呼吸操作变更和观察数据，分秒必争，说惊心动魄也不为过，可能是笔者从业以来经历的最危险项目之一。
除了前述的一些技术手段之外，整个项目组的QA小伙伴们也勤奋的进行多轮回归测试，发现了大量集群问题，功能测试的设计和执行仍然发挥了决定性的作用。
在重大的项目中，测试PM可发挥的空间和余地是巨大的，如果说整个项目是一艘巨轮，测试PM就是迷雾中的那个灯塔，避免巨轮偏向危险的航道。
测试PM要比项目PM更了解这个航道上礁石在哪里，提前识别风险，这基于对业务和系统理解，对风险的敏锐，这也依赖经验，需要从中小项目的锻炼做起。
测试PM需要勇敢的针对风险发出信号，也许会有误判，但是万一它是真的，也许会带来严重的后果，保持谨慎和敬畏。
测试PM在困难面前需要有强烈信心，突破边界，争取一切可能的支持，动用一切可能的手段来保障质量，你的坚定会打动你的伙伴。
如果你在一个质量团队，你一定要尝试担任几次大型项目的测试PM，对于你的个人成长非常有好处！
文章篇幅有限，探讨的内容有限，欢迎大家对感兴趣的内容继续探讨！
作者：神雕，shendiao@qunhemail.com
推荐阅读
公众号：酷家乐技术质量 知乎：酷家乐技术质量
TesterHome：kujiale-qa (酷家乐质量效能)